Within a database system, device and software failures, system resets, and power losses can result in unsuccessful write operations. During multi-sector writes, it is possible for a data transfer to be interrupted by software failures such as a node software “panic” or hardware failures such as node processor or memory errors, adapter failures, cable failures or loss of power to the system. This can result in partially written data, with some new sectors and some old sectors in the area that was to be written. This failure is known as an interrupted, a subset of unsuccessful writes.
FIG. 1 illustrates an interrupted database write operation. Referring to FIG. 1, a database write operation, WRITE DATA 101, is issued by database system 100 to storage subsystem 103 to write data to data block 107 within data storage device 105. A hardware or software failure, or other event, results in a successful write of only a portion 107A of data block 107, while the write to a portion 107B of the data block is unsuccessful.
Teradata Corporation database systems have employed HDD and SSD disk array systems from vendors that incorporate interrupted write protection into their products. In these implementations, when data in the interrupted write area is read, a special pattern is returned instead of the data. The database system can detect this pattern and optimize its recovery. That is, it can distinguish the special case of an incomplete write from that of general corruption, which is what the interrupted write would have looked like had the actual data been returned instead of the special pattern. This interrupted write protection is not available when using commodity storage such as direct attached disks or software RAID. These direct attached disks or software RAID devices are generic products which usually do not include interrupted write detection.
A system and method for providing interrupted write protection to a stand-alone commodity storage array is described below.